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Abstract 

The Java PathFinder, Jpf, is a translator from a subset of Java 1.0 to Promela, the 
programming language of the Spin model checker. The purpose of Jpf is to establish a 
framework for verification and debugging of Java programs based on model checking. The 
main goal is to automate program verification such that a programmer can apply it in the 
daily work without the need for a specialist to manually reformulate a program into a different 
notation in order to analyze the program. The system is especially suited for analyzing multi- 
threaded Java applications, where normal testing usually falls short. The system can find 
deadlocks and violations of boolean assertions stated by the programmer in a special assertion 
language. This document explains how to use Jpf. 
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1 Introduction 


This manual describes Java PathFinder (Jpf) [5], a translator from Java [3] [2] [1] to Promela, 
the programming language of the Spin model checker [7J. The purpose is to establish a framework 
for verification and debugging of Java programs based on model checking. The tool is named after 
the rover operating on Mars in 1997 called the u Mars PathFinder", and is a play on words: it finds 
the paths of a Java program that lead to errors. 

Spin is a verification system that supports the design and verification of finite state asynchronous 
process systems. Programs are formulated in the PROMELA programming language, which is quite 
similar to an ordinary programming language, except for certain non-deterministic specification 
oriented constructs. The Spin model checker can automatically determine whether a program 
satisfies a property, and, in case the property does not hold, generate an error trace. Spin also 
finds deadlocks. 

A significant subset of Java version 1.0 is supported by Jpf: dynamic creation of objects with 
data and methods, class inheritance, threads and synchronization primitives for modeling monitors 
(synchronized statements, and the wait and notify methods), exceptions, thread interrupts, and 
most of the standard programming language constructs such as assignment statements, conditional 
statements and loops. However, the translator is still a prototype and misses some features, such as 
packages, overloading, method overriding, recursion, strings, floating point numbers, some thread 
operations like suspend and resume, and some control constructs, such as the continue statement. 
In addition, arrays are not objects as they are in Java, but are modeled using Promela’s own 
arrays to obtain efficient verification. Finally, we do not translate the predefined class library. 

Note that many of these features can be avoided by small modifications to the input code. In 
addition, the tool is currently being improved to cover more of Java. Despite the omissions, we 
expect the current version of Jpf to be useful on a large class of software. A front-end to the 
translator checks that the program is in the allowed subset and prints out error messages when 
not. The translator is developed in Common Lisp, having a Java parser written in MoscowML 
as front end. A description of an application of Jpf to a game server can be found in [6]. 

The manual is written such that no previous knowledge about the Spin model checker is needed. 
All needed Spin technicalities are described in this document. 

The manual is organized around an example buffer program as follows. Section 2 describes how 
formal specifications of properties are stated as assertions in the Java code. Section 3 describes 
how one can guide the model checker to do a more efficient job by estimating how many objects 
are created by each class. Section 4 describes the example program and its specification. Section 5 
describes, step by step, the interaction with the system needed in order to model check the Java 
program. Section 6 gives some examples of errors that can be seeded into the example program, 
and the expected response by Jpf. Section 7 says a bit more about specifications, in particular 
how class local invariants can be specified. Finally, Section 8 describes the parts of Java 1.0 that 
currently cannot be translated. 
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2 Specifications 


As .,1, be described :n the Mowing. a Java pjjjj- - * S3 
boolean properties to be satisfied at violations, Jpp -ill look for 

interleavings trying to violate the assertions, in ini two threads r, and T, each try to 

deadlocks. A typical deadlock situation is orex ^ ^ ^ locks Rj „ now r, tries to 

lock two resources Ri and fli Suppose Ti I. situations of this 

lock R, and P, tries to lock ft, a deadlock situation has i^sen. 

kind independent of whether any an error trace showing how the cor- 

In both cases (assertion violation, deadloc ) P initial state . Since there currently 

responding p R°MELA pr0 S ra ^' e ^ suc h PROMELA traces, and since it is very hard 

is no automatic mapping back to J ava traces methods with which one can print 

to read the Promela traces, we have provided a set * printed „„ SplN . s 

out essential information from the program execution This information 

graphical message sequence charts as will be ^ 0 f methods defined in the 

Assertions and print for turning Java c^e 

Verify class shown in figure 1. The Verily threads and it contains a method for 

into atomic blocks executed without interleaving in the following, 

achieving non-determinism. The methods of this cla^ that they 

Generally, all the methods in the Verify class are defined as static y That 

can be called by just prefixing the method with the bodieg Q f these methods are of 

is, without instantiating the class into ano] ’ t ’ or changed by the programmer to 

no importance to the verification, the o es co ^ actually running the program on 

something different. Their contents only have Nofe that one is not 

the Java Virtual Machine, and hence may ave u signatures (number of arguments 

allowed to add new methods to in the Java program 

and their types) of the existing methods. The Verily class mu 
fo c^y of its methods are called. It can be found in the distribution. 

2.1 Assertion Methods 

The class confmns .wo (evened) ^ 

taking a string and a boolean argument. The string „„i y serves a 

ttrjy h *puS°^^ ^^^uence chart in c^ .be condition 
is violated. Examples of calls are: 


Verify. assart (count «» 6); 

Verify . assart ( "count !- '6". count — 6); 

Verify, assert count “ 6); 


2.2 Error Method 

In some cases a programmer knows 

text 9tring * 116 printed out on the message sequence Chart ' 
The following two statements are logically equivalent: 


if (x — 0) Verify .error ("x is zero"); 
Verify. assart ("x is zero'', x !■ 0); 
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class Verifyf 

public static void assart (boolean b){ 

if (!b) System. out .printing*** assertion broken"); 

> 

public static void assart (String s, boolean b){ 

if (!b) Systam.out .printlnC'*** assartion brokan : M ♦ s) ; 

> 

public static void arror (String s){ 

System, out .printing'*** arror : " ♦ s) ; 

> 

public static void print (String s){ 

Systam.out . println(s) ; 

> 

public static void print(String s.int i){ 

Systam.out .print In (s ♦ H : " ♦ i); 

} 

public static void print (String s, boolean b){ 

Sys tarn. out. print In (a ♦ " : " ♦ b) ; 

> 

public static void baginltomicOO 

public static void endAtomicOO 

public static int random (int max) { 

java. util. Random random - nav j ava. util. Random () ; 
int naxt * random. naxtlnt () ; 
if (naxt < 0)naxt * -naxt; 
ratura (naxt X (max + 1)); 

> 

> 


Figure 1: The Verify class 


2.3 Print Methods 

As mentioned earlier, the Verify class provides a collection of print methods with which one can 
print out information on Spin's message sequence charts to illustrate error traces. Each of these 
methods takes a string argument, which will be printed out, and in addition, two of the methods 
take a value to be printed, either an integer or a boolean. Examples of calls are: 

Varify. print ("method HALT called"); 

Verify. print ("valua of temp M ,x); 

Verify. print ("temperature ok", temp < 80); 

Note that a boolean will be printed as a 0 (false) or 1 (true). 

2.4 Atomic Execution Methods 

In some situations it may be needed to cut down the search space in order to verify a program 
within reasonable space and time. Code that is surrounded by cadis of the methods begin Atomic () 
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and endAtomic () will be executed in an atomic mode without interleaving from other threads being 
allowed. The following example illustrates how the initialization of an array is made atomic: 

public void initialize (M 
Verify .beginAtomicO ; 
for (x » 0; x < 10,x++) 
my_array[x] * -1; 

Verify .endAtomic 0 ; 

> 

Note that making code execution atomic in this way typically cuts down the state space, but that 
it may remove the possibility for certain interleaving errors to occur. It is, however, safe to apply 
around code that effects only local variables not accessible from other threads. But even in the 
unsafe case the technique may be useful to “hunt down” an error that one has suspicion about, or 
simply for doing various kinds of experiments on a model that is too big for efficient verification. 

The difference between using these two methods and using the synchronized keyword of Java 
is that the latter makes thread execution atomic with respect to a single object. In contrast, the 
code between beginAtomicO and endAtomic () wUl be executed atomically with respect to the 
whole program. 

2.5 Non-Deterministic Switch Statements 

The random method allows for writing non-deterministic switch statements. It returns a random 
number between 0 and max (both numbers included). It can only be called in a switch statement 
as follows ( and nowhere else ): 

switch (Verify.random(2)H 
case 0 : 
x - true; 
break; 

case 1 : 
y * true; 
break; 

case 2 : 
x =* true; 
y * true; 
break ; 

> 

When executing this program one of the three entries will be non-deterministically chosen (due to 
the coding of the random method). When translating it using Jpf a non-deterministic construct 
will be generated. For this translation it does not matter what the argument to the random method 
is - it has absolutely no effect on the translation, and is only used when executing the program. 
Note that the switch statement is generally supported and will get the normal meaning if the 
branching expression is qq£ Verify . random( . . . ) . 
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3 Verification Parameters in the Code 


A Java program may create an arbitrary number of objects of any of its declared classes. The 
model checker, however, only allows at most 2 objects of any class to be created, unless otherwise 
stated in the Parameters class by the user, as described in the following. 

Suppose a program contains three classes: Cl, C2, and C3. Suppose furthermore that we expect 
6 objects to be created of class Cl, 1 object to be created of class C2, and at most 2 objects of class 
C3. We can specify this in the Parameters class as done in Figure 9, where constants Cl-size and 
C2.size specify our estimates of the number of objects created from classes Cl and C2. The size 
of C2 (1, which is less than the default 2) need not be stated, but stating it will reduce the size of 
the pre-declared data area for this class. 

9 

class Paramstersf 

static final int Cl.sizs ■ 6; 
static final int C2_sizs - 1; 

} 


Figure 2: The Parameters class 
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4 A Program Example : The Bounded Buffer 

will be illustrated by analyzing a complete, small, but non-trivial Java program This pro- 
XT^ amongs.'he example, distributed, is described in * Hot* *££ w t 
specification of it, desired properties. The program contains an error, later w 'be 
tool. In order to generate error traces on message sequence charts, Verify . p 
have been inserted in relevant places in the code. 

4.1 The Buffer Class 

The Java program that we are interested in verifying properties about is a bounded buffer repre- 
sented by a single class. An object of this class can store objects of any kind (objects of subclasses 
nf the General top level class Object). Figure 3 shows the declared interface of this class. It 
contains a put method, a get method and a halt method. Typically there *11 * . - 1- 
producer threads that call the put method, and one or more consumer threads hat c^ the get 
method. The halt method can be invoked by a producer to inform consumers that .t w.ll no lo g 
produce values to the buffer. Consumers are allowed to empty the buffer safely after * 
a consumer calls the get method after the halt method has been called, and the buffer u .empty 
an exception object of class HaltException will be thrown. A class is an exception c ass 
subclass of the class Throwable. In particular, class Exception is a subclass of Throwa 

class HaltExcaption extends Except ion{> 

interface Buf f erlnterf ace { 
public void put (Object x) i 
public Object get() throws HaltException; 
public void h&ltO i 

> 


Figure 3: The Buffer interface 

Figure 4 contains the Buffer class annotated with line numbers for later reference. The class 
declares an array of length 3 to hold the objects in the buffer. In addition to the array, a couple of 
pointers are declared, one pointing to the next free location, and one pointing to the next , J J 
to be returned by the get method. The variable usedSlots keeps track of the current mun£r of 
elements in the buffer. Finally, the variable halted will become true when the halt method is 

Cal The three methods of the class are all synchronized (note the eynchro^z^ keywordj. Hence 
each of these methods will have exclusive access to the object when executed. That is, when one of 
t^e met^ds U called on the buffer object by a thread, the buffer gets locked to serve that thread 
and it is unlocked again at the end of the method call. The put method takes as parameter the 
object to be storedim the buffer and has no return value (void)^It enters a loop 
th e buffer is full (i.e. having 3 elements) in which case it calls the built in wait method. Calhng the 
c mXi wiiLn a synchronized method suspend, the cumnt thread »nd 
to execute synchronized methods on the object. Such another thread can then call the -notify 
method which will wake up an arbitrarily chosen waiting thread to continue past its waitO 
The notifyAll method wakes up all such waiting threads. 

When finally the put method gets past the while loop, it is known that the buffer has 
and the insertL. of the new object can be complete. In case the buffer was ,n bet empty, all 

The get method is a little bit more complicated because it also takes into account whether the 
buffer has been halted. Basically, it will wait until there is something 

this element, unless the buffer is empty and at the same time has been halted. In this case, a 
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1. class Buffar iaplaaants Buf farlntarf aca { 

2 static final int SIZE ■ 3; 

3. protactad Objact □ array - nav Objact [SIZE] ; 

4. protactad int putPtr * 0; 

5. protactad int gatPtr * 0; 

6. protactad int usadSlots ■ 0; 

7. protactad boolaan haltad; 

8. 

9. public synchronizad void put(0bjact x) { 

10. vhila (usadSlots « SIZE) 

11. try { 

12. Varify.print( M producar wait”); 

13. waitO; 

14. > catch ( Int arruptadExcapt ion ax) {>; 

15 . Varify . print ("put " , putPtr ) ; 

16. array [putPtr] ■ x; 

17. putPtr » (putPtr ♦ 1) X SIZE; 

18. if (usadSlots •• 0) notifyAllO; 

19. usadSlots++; 

20 . > 

21. 

22. public synchronizad Objact gat() throws HaltExcaption{ 

23. whila (usadSlots *■ 0 t ! haltad) 

24. try { 

25. Varify. print ("consumar wait"); 

26. waitO; 

27. > catch (IntarruptadExcapt ion ax) {>; 

28. if (haltad) { 

29. Varify . print ( "consunar gats halt axcaption") ; 

30. HaltExcaption ha ■ nav HaltExcaptionO ; 

31. throw (ha); 

32. }; 

33. Varify. print ("gat", gatPtr) ; 

34. Objact x - array [gatPtr] ; 

35. array [gatPtr] - null; 

36. gatPtr - (gatPtr ♦ 1) X SIZE; 

37. if (usadSlots »* SIZE) notifyAllO; 

38. usadSlots — ; 

39 . raturn x ; 

40. > 

41. 

42. public synchronizad void halt(){ 

43. Varify .print ("producar sats halt flag"); 

44. haltad - trua; 

46. notifyAllO; 

46. } 

47. ) 

Figure 4: The Buffer class 
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„ „ 0thetwiM th e next buffer element 1. returned, and producer, are 

» *** - - be — * 

4.2 Setting up an Environment ^ a wlt hi„ 

T J e - verify properties about this c ass, buffer. We say that we set up an 

which it occurs, we can create a 9mal1 we prove pr0per ^ 

environment consisting of a number of thre s i acce ^ test i n g the buffer. Concretely, we s 

22 £ SC “cr^ a Consumer Cam. and then — *■ — 

shown in the main method in Figure 5. 

Cl ^blic 1 stitic void main(Strin g n *rgs) { 

Buffer b • new Buffer O ; 

Producer p - new Producer(b); 

Consumer c - new Consumer (b); 

> 

} 


Figure 5: The main program 

Finn, in orde, to illustrate the trap’s »gMli^ “ £’dltod, 
obiects that are to be stored m the buffer, see t gu nam e M the class takes a 

contains one integer variable Th ' extends this class with another fe 'l 
parameter and store, it in ™ ^eL, and then calls the super dam constructor 

and defines a constructor, which takes v 
with the first parameter. 


class Attribute 
public int ^ttr; 

public Attribute (int attrH 
this. at tr ■ attr; 

} 

> 

class AttrData axtands Attributat 
public int data; 

public AttrDataUnt attr. int data)f 
supar(attr) ; 
this. data ■ data; 

} 

} 


Figure 6: The Attribute and AttrData classes 


The producer and coueumer threat « 

fieures 7 and 8. The Producer class extends the Thr started with the start method, 

run method, which is then executedwhen an ^ J«c thig 3tart method in addition to stonng 

As can be seen, the constructor of the class “ “ he run metho d adds 6 AttrData objects 

locally the buffer for which elements ™ ll pd } 3quares as data, and then calU the hal 
to the buffer, with attributes 0 ... 5 (m that order; an 

method on the buffer. 
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The Consumer class also extends the Thread class. The run method stores all received objects 
in the received array (or at most 10 of them). Note how the receiving loop is written inside a 
try construct, which catches and prevents a Halt Except ion from going further. 

class Producer extends Thread { 
static final int COUNT « 6; 
private Buffer buffer; 

public Producer (Buffer b) { 
buffer ■ b; 
this . start () ; 

> 

public void run() { 

for (int i - 0; i < COUNT; i>+) { 

AttrOata ad • new AttrOata(i , i*i) ; 
buffer .put (ad) ; 
yieldO ; 

}; 

buffer .halt () ; 

} 

> 


Figure 7: The Producer class 


4.3 Property Specification 

Two assertions in Figure 8 state the properties we want to verify. The first assertion states that 
the consumer receives exactly 6 elements from the buffer. The second assertion within the for loop 
states that the received elements are the correct ones (at least wrt. the attr value). In addition to 
these assertions, the system will look for deadlock situations, which need no explicit specification 
by the user. 

4.4 Predicting Number of Objects Created 

As can be seen from Figure 7, the producer creates 6 AttrData objects. Since the default number 
of objects that can be created is 2, we need to specify 6 as the new limit. This is done in the 
Parameters class in Figure 9. 


12 



class Consumer extends Thread { 
private Buffer buffer; 

public Consumer (Buffer b) { 
buffer * b; 
this.startO ; 


public void run() { 
int count - 0; 

AttrData □ rscaivsd - new AttrData[10] ; 
try{ 

while (count < 10>{ 

received [count] - (AttrData) buffer. get () . 
count++ ; 


> 


> 


catch(HaltException •){>; 

Verify . print ( " Consumer ends ), 

Verify . assart ("count !» COUNT” , count ■* 
for (int i - 0; i < count; i++H 

Verify . assert ("wrong value received". 


Producer . COUNT) 


receivedCi] .attr 


} 


i) ;> 


Figure 8: The Consumer class 


cine* Parameters { 

static final int AttrData.sixe - 6; 

y 


Figure 9: The Parameters class 
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5 A Guided Tour 


This section describes how one model checks a Java program. The reader is assumed to know how 
one generally writes, compiles and executes Java programs. In addition, the system must have 
been installed as described in the installation guide. This means basically that the following two 
scripts must be available: 

• xspin : the graphical interface to Spin. 

• jpf ; the Java to Promela translator. 

5.1 Compiling, Executing and Translating the Program 

The Java program must be stored in a file of the form: myprogram . java. First you should compile 
the program to check that it is a valid Java program in the first place: 

jmvac myprogram . j a va 

Compilation should always be applied for the purpose of type checking the program before the 
translator is applied, since the translator assumes a well-formed Java program. 

Try now to execute the program by typing: 

java Main 

The most likely result will be the following: 

$ java Main 

put : 0 

gat : 0 

consumer vait 

put : 1 

gat : 1 

consumer wait 

put : 2 

gat : 2 

consumer vait 

put : 0 

gat : 0 

consumer vait 

put : 1 

gat : i 

consumer vait 

put : 2 

gat : 2 

consumer vait 

producer sets halt flag 

consumer gets halt exception 

Consumer ends 

We see how the verify .print statements in the code print out on the standard output, and the 
program terminates normally. Note, however, that due to “non-deterministic" scheduling of Solaris 
threads (into which Java threads are mapped when the Java Virtual machine is version 1.1.5 or 
newer), the execution may in fact choose a different path, and break an assertion since our program 
is bugged. The chan ce that it does is, however, very low (less than 5% according to our measures). 
Hence, the chance of catching the error by normal testing is equally low. Try to see if you can 
break the assertion by executing the program several times. 

Now to translate the program into Promela, type: 
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jpf myprogram 


Note that you should not give any .java suffix. This call will translate the file myprogram . j ava 
into a Promela program, which is written to the file: 

myprogram- spin 

This file can now be loaded into Xspin. In the following we describe how to set up XSPIN and how 
to load and model check the program in myprogram. spin. 

5.2 Setting Spin Options 

Xspin is called as follows: 


xspin 


A, a result, .Sell, window pops up as sho»n In figure 10 (the bod, of the wil d.. mil, h owever.be 
initially empty). From now on, the interface is Spin’s interface. To load the translated Promela 
program select FILE: Reopen. This will result in the window shown in the figure. 


1— kpiN CQN"rttOL r 3.2 .2 ~ 

20 SS 

i Hi 998 — Flier^exportyhoi^ 

Filer. Edit Jij 

Jhjn4 Help 



/* promela code generated from well formed Java program */ 

,*..«**•******************•************************* * 


/* verification Operations V 

fdefine veri fy_error_(msg) \ 
atomic{ \ 

pri ntf ("MSC: *** error : msg\n N ); \ 
assertCfal se) \ 

> \ 

|#defme veri fy_assert2_Cmsg , prop) \ 
atomic{ \ 
if \ 

: : prop \ 

: else -> \ ... v 



Figure 10: Spin main window 


The first time the Spin window appears a number of options have to be set before model ch g 
can be started. We shall go through these options in the following. If you dick on the RUN b 
a menu with the following possibilities, amongst others, appear: 


• Set Simulation Parameters 

• Set Verification Parameters 

• (Re)Run Verification 
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First dick on RUN: Set -Simulation-Parameters. This brings up the window shown in Figure 
11. You should change one on-off Held, namely the Data-Values-Panel field, to off as shown on 
the figure. This is to avoid slow down of the simulator while printing error traces generated by the 
model checker. Then click on the Cancel button (the option will actually be set as specified). 


.“1 Simulation Options j ^j]J 

!' — — 

| ® KSC Panel - wl th: 

1 ♦ Step Number Labels 

v* Source Text Labels 

l ♦ Normal Spacing 

Condensed Spacing 
J Time Sequence Panel - with: 

♦ Random (using seed) ^ 

•niv*M [j 

Cuided (using pan. trail) 

•—■‘"■•I 0 

Interactive 

♦ Interleaved Steps 

| v One Window per Process 

v One Trace per Process 

_J Data Values Panel 
W Track Suffered Channels 

* ■ Track Global Variables 

>-J - .Track \ .... 

J 01 splay W* 'show' In BSC 

_J Execution bar Pinal"* ~ r 

J i 

1 1 1 q 3 



Figure 11: Spin simulation options 


Now, in the Spin window (Figure 10) click on RUN: Set-Verif ication-Parametera. This brings 
up the window shown in Figure 12. Turn off the Report -Unreachable-Code option as shown in 
the figure. 




♦ Safety (state properties) 
II Assertions 
V Invalid Endstates 

♦ Exhaustive I 

v Supertrace/81 tstate 1 

v Hash-Compact 1 

rrwMfflii u— 1 



-J Apply Never dll* (If Present) 
-J Report Unreachable jCOde t 

-1 Check xr/xs Assertions 

CVerlfy an LTL Property] J 

(Set Advanced Options] j| 

Help | Cancel Run || 


Figure 12: Spin verification options 


Next, click on Set-Advanced-Options. This will create the window shown in Figure 13. Enter a 
-J in the Extra-Run-Time-Options field as shown on the figure. Also, activate Use -Compression. 
Then remove the two verification option windows by hitting respectively Cancel (figure 12), and 
Set (figure 13). This will set the options. 

We shall just mention a few other parameters that may have importance. First of all, the 
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, .pprox^jl 

Estlnmted SUM Spec* SIM * 10A3): (WO - 

Maximum Search Depth (step*): 

Extre Compile-Time Directives (Optional): f~ 

Extra Run-Time Options (Optional): l~^~ 


txpliln 
txpliln 
” Choost 
~ Choost 


1W*— 


» I — 

♦ Stop at Error Mr: |1 
^ Don't Stop at Errors 
j Sava All Error-trails 
j Find Shortest Trail (costly!) 


0 Use Partial Orde'r Reduction 
■ Use Compression ^ ] r »Ar 
j Add Complexity Profiling 
j c ompute Variable Ranges ^ 

Cancel | Set 


Figure 13: Spin advanced verification options 


Supertrace/Bitstate option (Figure coX*™ 

ignored during model checking, hence r mo del is too big for verification. 

Sors may then not be caught. This option can ^ (dead- 

Second, one of the two options S * f et * , e one may want to look only for deadlocks, 

locks) (Figure 12) may be turned off. For example, 

ignoring the assertions in the program^ M »mnrv-Available, Estimated-State-Space Size, 

£*£>££** explain buttons to get an explanation. 

5.3 Model Checking . . .. spin window 

To activate the Spin model program, which when executed 

(Figure 10). Spin will now compile the PROM EL a p gr window pops up with 

£, the model checking. While the hy spin complete," When 
the text: "Please wait uhtrt 'r^Xrlt^ Siting (the now generated C program). When 
this window disappears, the model ch ** appear9 as shown in Figure 14. 

this terminates, a window with the verrfUatom * l ^ further down it states: “errors : 1 • If 
In our case it says (top line)- a® 8 ® ^ error, as in our case, an extra window pops 

there are no errors “errors : 0’ is printed. If there is an this point. Spin has created an 

up as shown in Figure 15, which suggests actmns to b^ ^ake 3 ^ 1011 . We shall l now 

error trace, leading from the initial P™ 8 ™™ simulation That will create yet the window shown 
simulate that error trace. Hit .Run-Gun d m cause the error trace to be executed 

iS wS Z — will how cause printing on a graphical message 

line) puts 3 values mto the buffer, m pos ’ notifies the producer, indicated by a (red) 

consumer get, the Srs, .due (in positio n 0) ^ ‘h en ^l.l^ ^ produ<;er put$ *. 

arrow. Then the consumer gets the two rmnar a S drculat) etc At lhe end. the producer puts 
fourth value into position 0 (recall h consumer. Then the producer sets the halt. 

the las, sixth value in condition halted in line 27: 

flag. When the consumer now calls the get metnou, 

if (halted) < 


17 


g 


"TTnr 


7ZM 




pan: assertion violated 0 Cat depth 394) 
pan: wrote part_1n. trail 
(Spin Version 3.2.4 — 22 October 1998) 
Warning: Search not completed 

♦ Partial Order Reduction 
Compression 


Full statespace search for: 
never-claim 
assertion violations 
cycle checks 
invalid endstates 


- (not selected) 

- (disabled by -OSAFETY) 


State-vector 456 byte, depth reached 464, 
709 states, stored 
275 states, matched 
984 transitions (» stored-wnatched) 
139 atomic steps 
hash conflicts: 0 (resolved) 

(max size 2 ai 9 states) 

2.787 memory usage (Mbyte) 

nr of templates: [ global s procs chans ] 
collapse counts: [ 152 157 237 19 ] 


errors: 1 



Figure 14: Spin error report: assertion violated 



Figure 15: Actions suggested by Spin 


will evaluate to true, and an exception will be thrown. Hence, the consumer does not get the last 
value. The correct code for this line is: 

if (uwedSlota ** 0) { 

You may want to correct the program, and then try inserting your own errors, or the ones suggested 
in Section 5.4. 

Note that if the Java program does not contain any Verify .print statements nothing will get 
printed on the message sequence chart. Spin will print a Promela error trace in the window 
shown in Figure 16, but this Promela trace is hard for a human to relate back to the Java 
program, and is not recommended as a source of information. 

5.4 Error Messages 

Even if program compilation is successful, Jpf may still yield error messages. There are two sources 
of such. 
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warm no - lina 692 M par\_ln". d-*t«p insld# atomic 
warning: Iim 692 "pan_in», atomic insld* atomic Ognorad) 
i. ni **aan_in M . d_st<p insida atomic 
Mwnfl: Iinr 6« ■ »^ 1C ,n fW a '°"" a OflnorM) 

1 - r ";2: j;s \l\ "C!?: !S!S SEc <'•»'*» 

|wa r ° proc S linT728 "pan_m" (state ♦) 

(Main_Next_+l)] 


~‘ ir . Canctl } 


Figure 16: Simulation choices 


the following class definition: 

clast Operators { 
int z; 

public void shift_lait(int i){ 

z «- i; 

} 

using an alignment operator («-) no. supported ^^ .^^W^r^laUng -*£- 
rs case r- in a method, -« 

which method. 
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Figure 17: Message Sequence Chart for assertion violation 
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Figure 18: Error messages when outside translated subset 
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6 Verification Experiment 

In order to illustrate the effectiveness of .Jpf (and Spin of course) we have seeded 21 errors in the 
program shown in Figure 4, and for each error analyzed the now incorrect program using Jpf. 
First, however, we have corrected the program as indicated in Section 5.3 by changing line 28 to: 

if (uscdSlots »■ 0) { 

This yields a correct program as starting point. The result of the experiment is shown in Table 
1. For each error we give the line numbers changed, referring to Figure 4, and the new contents 
of these lines. As an example, error 1 is obtained by changing line 4 to “protected int putPtr 
* 1; (initializing to 1 instead of to 0). Error 14 was the one seeded into the program from the 
start. 

The results of applying Jpf are shown in the fourth column. That is, the result of applying the 
Spin model checker to the Prom el a code generated by Jpf. The possible outcomes are deadlock 
(D) and any of the two assertions being violated (A1 referring to the first occurring “count « 6” 
and A2 referring to the second “received [i] .attr “ i”). The point here is that all the errors 
are caught. 

The last two columns show the result of running the modified Java program on two versions 
of the Java Virtual Machine (Jvm) in order to see whether plainly executing the program would 
highlight the errors seeded. Jvm version 1.1.3 is an older version being very deterministic. This 
means that executing a multi-threaded program several times typically yields the same result 
every time. Jvm 1.1.6 is the newer version with native threads , where Java threads are mapped 
to Solaris threads. This version is therefore non-deterministic, potentially yielding different results 
for different runs of a multi-threaded program. 

Every program has been run several times (from 30 to 100), and the numbers indicate the 
percentage of runs that have highlighted the error, either via a deadlock, an assertion violation, or 
a thrown NullPointerException. 

All runs, model checking as well as Jvm runs, have been executed on a Sun Ultra Sparc 60 with 
512 Mb of main memory, and with the Solaris operating system version 5.5.1. 

Running the Spin model checker on the Promela code generated by Jpf typically used less 
than half a second to find an error and explored between 40 and 400 states and a similar number 
of transitions. In a few cases (error 8 and 10) approximately 10000 states and 18000 transitions 
were explored in less than 2 seconds. 

“Errors” 11 and 20 are special (marked with a *) in the sense that they are not really errors 
when using the environment described in Section 4.2. This environment only creates one consumer, 
and to make the errors manifest themselves, we needed to create two consumers as shown below: 

class Main { 

public static void nain (String □ args) { 

Buffsr b - naw BuffarC) ; 

Producar p ■ nav Producar(b) ; 

Consular cl ■ nav Consular (b) ; 

Consular c2 » nav Consular (b) ; 

} 

> 

In addition, with two consumers the assertions make no sense and were deleted. Hence, we 
were now just looking for deadlocks. The table rows for these errors show the result of verifying 
and executing in this changed multi-consumer environment. The verification of error 11 needed as 
much as 8 minutes, exploring 2.4 million states and 6 million transitions before the deadlock was 
found. We verified a down scaled version of this error, with a buffer size of 2 (instead of 3) and the 
producer only producing 3 values (instead of 6). Also here the deadlock was found by the model 
checker, but now using 1 minute, and exploring 423096 states and 1 million transitions. 
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Table 1: Vprification results 

Nr. 

Line 

Modification (changed to) 

JPF 

Jvm 1.1.6 

Jvm 1.1.3 

1 

4 

protected int putPtr ■ 1; 

A2 

100 

100 

2 

6 

protected int usedSlots * 1; 

Al, A2 

100 

100 

3 

10 

while (usedSlots !=■ SIZE) 

D 

100 

100 

4 

10 

while (usedSlots « 2) 

D 

65 

0 

5 

16 

putPtr * (putPtr + 1) X SIZE; 

A2 

100 

100 


17 

array [putPrt] * x; 




6 

17 

putPtr = putPtr X SIZE; 

A2 

100 

100 

7 

17 

putPtr * (putPtr + 1) X 2; 

A2 

56 

0 


36 

getPtr a (getPtr + 1) % 2; 




8 

18 

if (usedSlots SIZE) notifyAllO; 

D 

33 

100 

9 

18 

remove: 

D 

55 

100 



if ( usedSlots == 0) notify All(); 




10 

mm 

usedSlots++; 

D 

35 

100 


H 

if (usedSlots == 0) notifyAllO; 




11* 

18 

if (usedSlots == 0) notifyO ; 

D 

2 

100 


37 

if (usedSlots ** SIZE) notifyO; 




12 

23 

while (usedSlots ** 0) 

D 

100 

100 

13 

28 

if (usedSlots !* 0) { 

Al, D 

100 

100 

14 

28 

if (halted) { 

Al 

3 

0 

15 

37 

if (usedSlots 0) notifyAllO; 

D 

50 

0 

16 

37 

remove: 

D 

44 

0 



(if usedSlots == SIZE) notifyAllQ; 




17 

37 

usedSlots — ; 

D 

66 

0 


38 

if (usedSlots -* SIZE) notifyAllO; 




18 

38 

usedSlots++ 

Al, A2 

100 

100 

19 

44 

remove: 

D 

100 

100 



halted = true ; 




20* 

45 

notifyO ; 

D 

2 

100 

21 

45 

remove: 

D 

100 

100 



notifyAllO; 
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7 Specifying Invariants 

As described in Section 2 a Java program can be annotated with assertions placed in the code in 
relevant positions. When execution (by the model checker for example) “hits” the assert statement, 
the condition will be checked. That is, the assertion will only be checked when “i t gets its turn to 
execute”. 

Suppose we instead want to state a general invariant about part of the variables in the program. 
That is, suppose we for example want to verify that the value of the variable usedSlots in the 
Buffer class is always! less than or equal to 2 (which is wrong, it can become 3). We shall see 
solutions of how to specify and verify this in the following. 


7.1 Assertion in the Code 

The first solution follows a standard strategy of inserting an assertion in the code where the variable 
usedSlots is incremented, as illustrated in Figure 19. The changed (added) line begins with the 
symbol: 

public »ynchroniz*d void put (Obj.ct x) { 
whilo (uaodSlota — SIZE) 
try { 

V«rif y. print ("producer wait"); 
vmitO ; 

> catch (Int«rrupt*d£zc«ption ax) {>; 

Varify .print ("put" , putPtr) ; 

array [putPtr] » x; 

putPtr - (putPtr ♦ 1) X SIZE; 

if (usadSlots «» 0) notifyAllQ; 

usadSlota++; 

* Varify. assart ("usadSlots > 2", usadSlots <■ 2); 

> 


Figure 19: Invariant as assertion in the put method 

This solution has the advantage that as soon as the assertion is broken (if broken), the model 
checker will detect this. Hence, there is a slight advantage wrt. verification time used to locate 
an error. Also, the generated error trace typically also is shorter than when using the alternative 
techniques to be described in the following. 

The disadvantage of this technique is course that we have to figure out where the variable 
is updated. In case of mere complicated invariants involving more than one variable, this may 
become messy and error prone. The remaining solutions do not have this disadvantage, but they 
may require more time to locate an error. 

7.2 Invariant in the main Method 

An alternative solution is to place the assertion in the main method after having started all threads. 
There are two ways of doing this as described in the following. 

7.2.1 Directly as an Assertion 

Figure 20 illustrates how the assertion is inserted at the end of the main method, after all objects 
have been created and all threads have been started. The assertion now refers to the variable 
b. usadSlots, hence, it refers to the variable through the object b. 

The way it works is as follows. The main method will start all the threads, and then continue 
itself as a thread running in parallel with these other threads. In particular, it will be ready to 
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execute the assert statement at any time. The model checker will therefore execute it in any state. 
Hence the assertion will function as an invariant that has to hold at any time. 

class Main { 

public static void main (String [] args) { 

Buffer b ■ new BuffarO ; 

Producar p * new Producar(b) ; 

Consumar c ■ nan Consumar(b); 

* Var if y. assart ("usedSlots > 2" ,b. usedSlots <■ 2); 

} 

> 


Figure 20: Invariant as assertion in the main method 

A disadvantage of this technique is that the state contents of the Buffer class is revealed in 
the main program: it for example only works if the variable usedSlots is accessible from outside 
the class. In this case it is since it is protected, and such a variable is visible within the package. 
Had it, however, been private, we could not have used this technique. The next solution solves 
this problem, and is just as efficient. 

7-2.2 Indirectly by Calling an Invariant Method 

In order to make an invariant local to a class, one can state it in a method defined in the class, 
and then call this method in the main method. This is illustrated in Figure 21. Note that we can 
name the invariant method as we like, and it can also contain as many assertions as we like. We 
can even define several invariant methods, and call only some of them at convenience. 

class Buffer implements Bufferlnterface { 
static final int SIZE * 3; 

protected Object □ array * new Object [SIZE] ; 

protected int pntPtr * 0; 

protected int getPtr * 0; 

protected int usedSlots * 0; 

protected boolean halted; 

* public void invariant (H 

* Verify .assert ( M usedSlots > 2'* , usedSlots <* 2); 

* > 


} 


class Main { 

public static void main (String [] args) { 
Buffer b * new Buf ferO ; 

Producer p * new Producer (b) ; 

Consumer c u new Consumer (b) ; 

* b. invariant () ; 

} 

> 


Figure 21: Invariant as method call in the main method 
The advantage of this method is that now the invariant is really local to the class. The disad- 
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vantage is that one still needs to call the invariant method in the main program, which again 
means that the buffer object b must be visible in the main program. The last solution solves this 
problem. 

7.3 Invariant as a Thread 

The final solution consists of defining the Buffer class as an extension of the Thread class, and 
then define the required run method to contain a call to the invariant method. This is shown in 
Figure 22. The figure shows how the Buffer class has been extended with an invariant method, 
a run method that calls this invariant, and a constructor that starts the thread. Hence, whenever 
a Buffer object is created with the new method, a thread is started that at any time may check 
the assertion. Again, several invariant methods can be defined and called. One can also write the 
assertions directly in the run method. 

* class Buffer extends Thread implements Buffer Interface { 

protected Object □ array - new Object [SIZE] ; 

protected int putPtr « 0; 

protected int getPtr *0; 

protected int usedSlots - 0; 

protected boolean halted; 

* public void invariant (){ 

* Verify. assert ("usedSlots > 2" .usedSlots <- 2); 

* > 

* public void run() {invariant () ;> 

* public Buffer () {this .start () ;} 


> 


Figure 22: Invariant as a thread 

The disadvantage of this technique is that it only works for passive classes that are not already 
extensions of the Thread class. 
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8 Features of Java 1.0 Not Translated 

Jpf translates a subset of Java 1.0, and this section identifies the features not translated, each 
devoted a subsection in the following. Java 1.0, in turn, is a subset of Java 1.1, which in addition 
provides, amongst other things, inner classes. Consequently, Jpf does for example not translate 
inner classes. A good and relatively short description of Java 1.0, and the extension Java 1.1, can 
be found in [2]. 

The translator should print out error messages if the Java program is not within the translated 
subset. In the following cases, however, no error messages will be printed even though these 
features are not translated: method overloading, method overriding, and method recursion. The 
Spin syntax checker will, however, complain and reject the translated Promela program. Since 
Spin’s error messages may not be easily related to the Java program it should preferably be 
reassured by human inspection that the jAVAprogram does not use any of these features. 


8.1 Compilation Units 

A Java program must consist of a single package. References to other packages, user-defined 
as well as predefined Java packages, such as java.lang, are not allowed. Consequently, import 
declarations are not allowed. 

As a consequence, class names must either refer to user-defined classes or to one of the predefined 
classes: Object, Thread, or Exception. 

8.2 New Names 

A user-defined name cannot end with underscore: V. The reason for this is that internal names 
generated by the translator end with V. 

8.3 Predefined Types 

The following primitive types are not allowed: char, float, and double. The type String is 
furthermore not allowed. Literals of these types are not allowed to occur in the program. 

8.4 Subclassing 

In a class declaration of the form: 

class SomeClass extends Superclass { . . . 1 

the Superclass must either be a user-defined class or one of the pre-defined Java classes: Thread 
or Exception. 

8.5 Variable Declarations 

8.5.1 Modifiers 

The native modifier is not allowed in instance variable declarations. 

8.5.2 Array Declarations 

Arrays must be one-dimensional and must be given a dimension at declaration time in terms of an 
integer literal, or alternatively in terms of an array initializer, as in the following examples: 

static final int SIZE * 7; 

int [] ia * new int [5] ; 

Object [] oa * new Object [SIZE] ; 
byte[] ba ■ {1,9,9,91; 


27 



Note that if a constant (static and final) is used to define the size of an array, this constant cannot 
be defined in terms of other constants - it has to be defined directly representing some integer 
literal as in the above case (note that this is only a restriction on constants used in defining array 
dimensions). Hence, the following is illegal: 

illegal: 

static final int BIGGER.SIZE - SIZE ♦ 1; 
int [] b ■ new int [BIGGER.SIZE] ; 

The array brackets [] have to occur in combination with the type. For example, the following 
declaration where the [] brackets are associated with the array variable a is not allowed: 

illegal: 

int a[] * new [5]; 

8.6 Methods and Constructors 

8.0.1 Modifiers 

The following method modifiers are not allowed: abstract and native. 

8.6.2 Overloading and Overriding 

Methods and constructors cannot be overloaded and methods cannot be overridden. As a conse- 
quence there can be at most one constructor per class. However, each subclass of a class can have 
its own constructor. 

8.6.3 Recursion 

Recursive methods are not allowed. 

8.6.4 Names of Called Methods 

Except for user-defined methods only the following pre-defined Java methods can be called: 
start stop slaap yiald wait notify notifyAll 

8.6.5 Array Argument and Return Types 

The type of a method or constructor argument cannot be an array type. Similarly, the result type 
of a value returning method cannot be an array type. 

8.6.0 Actual Parameters in Calls 

Actual parameters in method cadis cannot themselves be method calls. 

8.7 Expressions 

8.7.1 Names 

Names occurring in expressions or on left-hand sides of assignment statements must be user-defined. 
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8.7.2 Object Instantiations 

An object instantiation using the new operator is only allowed in association with a variable 
declaration or in an assignment statement, as illustrated here: 

SomoClass s - new SomeClass (42) ; — in a declaration 
OtherClass t; 

t * new 0therClass(43) ; — in an assignment statement 

Similarly, an array instantiation using the new operator can only (and must) occur in an array 
declaration as discussed in Section 8.5.2. 

8.7.3 Assignment Expressions 

Assignments are not allowed as expressions. For example, the following is not allowed: 
illegal: 

x * (y » y ♦ 1) ; 

8.7.4 Unary Expressions 

The following unary expressions are not allowed: 

illegal: 

— expr ++expr expr — expr++ ~expr 
The first four of these are, however, allowed as statements! 

8.7.5 Binary Expressions 

The following binary operators are not allowed: 

illegal: 

<< >> >>> instanceof * 

8.7.6 Ternary Expressions 

Ternary expressions of the form: (exprl?expr2:expr3) are not allowed. 

8.8 Statements 

8.8.1 Switch Statements 

Each entry statement not being the last in a switch statement should exit with a break or return 
as for example in the following program: 

switch (x){ 
case *1 : 
case 0 : 

case 1 : near. zero * true; break; 
default : near. zero * false 

> 
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This statement will assign true to near .zero if x is either -1, 0 or 1, and otherwise false. Now, 
if we remove the break statement, and x has the value -1, 0 or 1, it will first assign true and then 
false, resulting in false. The switch statement is said to u fall through” from the first case to the 
second case. This behavior is not supported, and the translator will insert the break statements 
if they are not present. 

8.8.2 Continue Statements 
Continue statements are not allowed. 

8.8.3 Labeled Statements 
Labeled statements are not allowed. 

8.8.4 Try-catch-flnally Statements 

A catch in a try statement is only allowed to catch exceptions of user-defined exception classes 
or exceptions of the classes Exception, InterruptedException or ThreadOeath, the latter being 
thrown by the stop method. 
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